home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000078_owner-urn-ietf _Wed Nov 6 20:16:44 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA20903 for urn-ietf-out; Wed, 6 Nov 1996 20:16:44 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA20898 for <urn-ietf@services.bunyip.com>; Wed, 6 Nov 1996 20:16:42 -0500
  3. From: jayhawk@dsm0.ds.internic.net
  4. Received: from dsm0.ds.internic.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  5.         id AA15963  (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:16:41 -0500
  6. Message-Id: <9611070116.AA15963@mocha.bunyip.com>
  7. Date: Wed, 6 Nov 96 20:16 EST
  8. To: jayhawk@ds.internic.net, sollins@LCS.MIT.EDU
  9. Cc: urn-ietf@bunyip.com
  10. Subject: Re: [URN] Comments on "I18N does not belong in URNs"
  11. Content-Length: 2341
  12. Sender: owner-urn-ietf@services.bunyip.com
  13. Precedence: bulk
  14. Reply-To: jayhawk@dsm0.ds.internic.net
  15. Errors-To: owner-urn-ietf@bunyip.com
  16.  
  17. Karen R. Sollins said:
  18.  
  19. >Ryan Moats said:
  20. >
  21. >   Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD
  22. >   REASON and consensus.  (This is a null statement, but I wanted to make
  23. >   it anyway).
  24. >
  25. >It is informational because it is neither the specification of a
  26. >protocol nor the specification of protocol payload, and therefore
  27. >cannot be standardized.  Beyond that, consider it a standard.  It is
  28. >the base from which we are working.  We went over all much of the
  29. >ground be rediscovered here and more and reached consensus in order to
  30. >produce 1737.  If we are always in a state of flux where we cannot
  31. >make assumptions based on previous consensus reached, we will NEVER
  32. >make progress and this is a futile exercise.  I'm sure we all have
  33. >better things to do.  So, take it as a given that RFC 1737 stands.  If
  34. >there is consensus that it doesn't, this working group must be
  35. >disolved.
  36. >
  37.  
  38. First I have to apologize, because I should have added an indication that
  39. that wasn't an entirely serious remark.
  40.  
  41. <MINOR SOAPBOX>
  42. Having said that, I still claim that as we move forward, we have the right
  43. to realize that something in 1737 isn't optimal or doesn't work etc.  My
  44. opinion is that if there is rough consensus in the WG, then saying "but
  45. 1737 says that's a no-no" doesn't cut it.
  46. </MINOR SOAPBOX>
  47.  
  48. In a more directed vein, syntax draft already breaks 1737. Specifically, I'm
  49. refering to the "case insensitivity" requirement (the draft current
  50. has the NSS being case sensitive). "Case-insensitivity" is itself
  51. tied up in what character set we use.  If we treat the NSS as a series of 
  52. octets, then we can't have case insensitivity, because we haven't set
  53. a character set (ho boy am I digressing...)
  54.  
  55. <OPEN ISSUE>
  56. I do have an issue that folks either haven't been thinking about or
  57. have tabled until other things get settled, and that is the
  58. whole escaping issue.  Will we ever want to escape octets of the URN
  59. at the client?  Now, I discount transport encoding with the assumption
  60. that the transport mechanism has to unencode the URN before passing it up.
  61. The syntax draft was written assuming that we would, but that seems to
  62. create all sorts of troubles if we allow namespaces to set up their own escape
  63. mechanisms (and allow non restricted octets in the URN).
  64.  
  65. Does anybody have an opinion on this?
  66. </OPEN ISSUE>
  67.  
  68. Ryan
  69.  
  70.